Since the advent of the Internet and network communication capabilities, users have come to expect that information and communication services are constantly available for personal access. People want fast, reliable access to information. In addition, most commercial users depend upon having Internet connectivity all day, every day of the week, all year long. To provide this level of reliable service, component and system providers have developed many proprietary solutions and operating-system-dependent solutions intended to provide servers having high reliability and constant availability.
The rapid expansion of wireless technology and the adoption of Internet Protocol (IP) in telecommunication networks and wireless infrastructures require that IP service be both reliable and available. One aspect of reliability is maintenance of the actual condition of the telecommunication network and each of the elements with the network to ensure that as many elements of a system know the active status of other elements. A telecommunication network is dynamic as elements enter and leave, information is processed, and applications are modified.
Existing services, such as Domain Name Service, and similar other network level look-up services do not reflect the actual condition of the network or network elements. When a user queries a Domain Name Service by providing a name, the Domain Name Service server returns one or more IP addresses. The client caches the returned Domain Name Service entries and forwards the request to the server. Yet, the Domain Name Service configuration is static and does not reflect the current state of the respective servers.
It is not practical to incorporate such dynamic functionality to the Domain Name Service server as the Domain Name Service entries have grown to a large number. Moreover, it may not be possible to monitor all the application servers in the Internet. If this monitoring system were attempted, the entire Internet would be inundated with a high volume of unnecessary traffic. Additionally, as to security issues, an intruder can generate false status data for queried elements. As can be appreciated by one skilled in the relevant art, new services are constantly being provided. These services need the correct current status of the related application server in order to provide uninterruptible real time service to clients. One such new service is a reliable server pool. The reliable server pool is a framework where different servers co-operatively form a pool to support a variety of clients in the supported network. However, the scope of the reliable server pool is typically not Internet-wide, a feature that restricts clients and application servers to one single administrative domain.
In a client-server environment, clients may access an application via one or more servers. In order to provide uniform access to the application through different servers and to evenly balance the load across the servers, there are known network configurations incorporating server load balancer, load sharing, and fault-tolerant systems. Equipment like load balancers perform proxy service to one or more servers in a server pool. The load balancers forward each client request to an available, i.e., less loaded, server. While these solutions are intended to improve the availability of the server itself, the client is still required to access a look-up service, such as Domain Name Service, to locate these servers. The Domain Name Service only performs simple name to address translation based on the static configuration and does not reflect the actual status of the located server. Further, load balancers are not a cost effective solution for all server pool systems.
For example, a particular server might have been down or had its IP address reconfigured for maintenance reasons. Clients that had previously cached the old entries that try to access these services will receive an error message from the network. This impacts both the user and the service provider. As Internet Protocol has been adopted by wireless and telecommunication industries, more services are expected in the near future with corresponding requirements for high availability. Further, there will be even more need for high reliability. Service providers need reliable service to compete.
As the number of static and mobile clients increases to access a particular service from a particular server, two fundamental problems result. First, if the application server goes down or if a node fails, service will not be available. Second, if the network connection between the user and the server has failed, the service will not be available to the user.
When a server fails, or otherwise becomes unavailable, the browser of the user may handle the task of switching to another server to continue an application service. Often, the browser will merely return an error message such as ‘URL not found.’ Alternatively, if the browser does access a replacement server, there are no considerations given to load sharing. Thus, there is a need to provide a reliable look-up service that both a user and server can use to improve their performance. Reliable Server Pool (Rserpool) is a known architectural framework that addresses these issues and it is being standardized within the Internet Engineering Task Force (IETF).
The present state of the art has defined an improved architecture in which a collection of application servers providing the same functionality are grouped into a reliable server pool to provide a high degree of redundancy. Each server pool is identifiable in the operational scope of the system architecture by a unique pool handle or name. A user or client wishing to access the reliable server pool will be able to use any of the pool servers by conforming to the server pool policy.
Several solutions have been proposed to address the issue of reliability and to ensure a distributed load across a server pool. One such solution is with the use of load balancers. One or more load balancers may be used, whereby selected application services are executed using multiple servers. The load balancer acts as mediator to direct different client requests to different actual servers, thus evening out traffic across all servers. However, the load balancer serves as a single point of failure. The application service may be physically distributed and similar hardware may be deployed so as to avoid a single point of failure configuration. However, this solution may be too costly for many network service providers. Redundant load balancers may be implemented to attempt to alleviate the single point of failure problem; however, any redundant load balancer must be connected to the same local area network segment as the first load balancer. Further, redundant load balancers increase the cost of the system, which again may not be the most suitable solution in every server pool system.
Moreover, there are different variations of load balancers, and each of them is tailored to solve specific application needs or network needs. These ‘middle-boxes’ may function at any of layer 2, layer 3, or layer 4 of the 7-layer Open Systems Interconnection (OSI) network model. Most middle-boxes provide availability to the client, but only if the client has already resolved the server IP address or if the client already knows the server location. Within the Internet, large content providers typically use such servers and each client must go through the Domain Name Service to perform initial address look-up. When the Domain Name Service returns a list of IP addresses, the client usually tries the first IP address and, if it is unavailable, an error message is returned. The next IP address in the list is not usually tried as a follow-up. The operation of attempting a connection to another IP address on the list is application dependent. For an application that uses Transmission Control Protocol (TCP), as per IETF standards, the number of connection attempts is eight. This situation can be avoided if the content provider binds its IP addresses to the same server(s), but this increases the traffic and load on the servers and this configuration provides no security mechanism.
In another approach commonly used in a distributed application, Common Object Request Broker Architecture (CORBA) middleware provides access transparency. CORBA is a middleware. It is a set of services that is developed by the Object Management Group. It is based on Object model and supports plug-able services, fault tolerance, and availability as part of a base communication mechanism. Different applications can use this to service the client request. Different mechanisms can be supported where non-CORBA applications (client or server) can access CORBA services using Interoperable Object References (IOR). The basic disadvantages of using CORBA are that not all applications need to have such high processing middleware and that there are interoperability problems in adopting CORBA middleware to Internet applications. COBRA is a standard and each vendor implements it in their own manner, requiring a great deal of message exchange.
Candidate Endpoint Name Resolution Protocol (C-ENRP) is a known protocol designed to provide a fully distributed fault-tolerant real-time translation service that maps a name to a set of transport addresses pointing to a specific pool of networked communication endpoints registered under that name. C-ENRP employs a client-server model with which an ENRP server will respond to the name translation service requests from endpoint users running on the same host or different hosts. However, an ENRP server pool system does not currently allow for a change to the load distribution among members of an ENRP server pool when one or more ENRP servers enter or leave the existing ENRP server pool. Further still, a current ENRP server pool system does not allow for each server within the existing ENRP server pool to know the current status of pool endpoints and other ENRP servers within the pool without a single point of failure.
Thus, it would be an advancement in the art to provide a cost effective solution that allows a network server to be added or deleted from a server pool, such as an ENRP server pool, while allowing for a change in the distribution of the application servers' handles by the various network servers in the pool. It would be a further advancement in the art to provide a solution that minimizes traffic and load on the servers while removing the single point of failure problem associated with a load balancer. It would be another advancement in the art to provide a solution incorporating a security mechanism.